En la clase ConcurrentQeueue<> , se define un método extra TryDequeue() . Pero, como implementa IProducerConsumerCollection<> , también tiene un método TryTake() . Según los documentos, ambos hacen lo mismo:
Intenta eliminar y devolver el objeto al principio de la cola concurrente.
Para ConcurrentQueue, esta operación intentará eliminar el objeto del principio de ConcurrentQueue.
¿Por qué molestarse en implementar ese método TryDequeue ?
¿Cuál es la diferencia entre TryDequeue y TryTake en ConcurrentQueue<>?
De acuerdo con el código fuente disponible, no hay diferencia ya que TryTake invoca TryDequeue
/// <summary> /// Attempts to remove and return an object from the <see cref="Concurrent.IProducerConsumerCollection{T}"/>. /// </summary> /// <param name="item"> /// When this method returns, if the operation was successful, <paramref name="item"/> contains the /// object removed. If no object was available to be removed, the value is unspecified. /// </param> /// <returns>true if an element was removed and returned successfully; otherwise, false.</returns> /// <remarks>For <see cref="ConcurrentQueue{T}"/>, this operation will attempt to remove the object /// from the beginning of the <see cref="ConcurrentQueue{T}"/>. /// </remarks> bool IProducerConsumerCollection<T>.TryTake([MaybeNullWhen(false)] out T item) => TryDequeue(out item);Fuente: https://source.dot.net/#System.Private.CoreLib/ConcurrentQueue.cs,201
¿Por qué molestarse en implementar ese método TryDequeue?
TryDequeue sigue las convenciones de nombres esperadas asociadas con las colas y es local para ConcurrentQueue<> . Además, TryTake sigue la convención de nomenclatura normalmente asociada con el patrón productor/consumidor.